Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FEQ] aum/FEQ-1654/pagelayout-improvements-remove-right-content-flex #48

Conversation

aum-deriv
Copy link
Contributor

@aum-deriv aum-deriv commented Jan 31, 2024

Changes

Remove the right section prop

  • Remove the right section prop and its corresponding rendering logic as it is decided that the right-hand side of the content will always be the part of the content. This is done to reduce the complexity for rendering the right-hand side as usually the content rendered in the content section has the control to change the behavior of the content on its right-hand side.

Fix: Content flex

  • Applying flex: 1 for the content section so that it can stretch to the entire width available to it.
Screen.Recording.2024-01-31.at.5.27.10.PM.mov

@aum-deriv aum-deriv marked this pull request as ready for review February 1, 2024 05:32
@aum-deriv aum-deriv force-pushed the aum/FEQ-1654/pagelayout-improvements-remove-right-content-flex branch from c0e3cab to 25ee8d8 Compare February 1, 2024 05:34
@shayan-deriv
Copy link
Contributor

shayan-deriv commented Feb 1, 2024

@aum-deriv need your opinion on this. how about instead of limit the layout to only have two columns we have sth more general where the consumer can pass as many columns as they need and control the style with props.

for instance this:

<Layout>
    <Column flex={1} classname="sidebar">...</Column>
    <Column flex={2} classname="content">...</Column>    
</Layout>

Screenshot 2024-02-01 at 2 29 29 PM

<Layout>
    <Column flex={1} classname="sidebar">...</Column>
    <Column flex={2} classname="content">...</Column>    
    <Column flex={1} classname="left-sidebar">...</Column>  
</Layout>

Screenshot 2024-02-01 at 2 29 46 PM

<Layout>
    <Column flex={1} classname="sidebar">...</Column>
    <Column flex={1} classname="content">...</Column>    
    <Column flex={1} classname="sidenote">...</Column>  
</Layout>

Screenshot 2024-02-01 at 2 29 59 PM

then the consumer can decide which one is suitable for their case. for instance maybe the accounts team want to use context to handle the shared data between content and sideNote then they can go with the second example or the cashier decide to use the first one.

what do you think guys?
@ali-hosseini-deriv @markwylde-deriv @aizad-deriv @amina-deriv @wojciech-deriv

@azmib-developer
Copy link
Contributor

@aum-deriv need your opinion on this. how about instead of limit the layout to only have two columns we have sth more general where the consumer can pass as many columns as they need and control the style with props.

for instance this:

<Layout>
    <Column flex={1} classname="sidebar">...</Column>
    <Column flex={2} classname="content">...</Column>    
</Layout>

Screenshot 2024-02-01 at 2 29 29 PM

<Layout>
    <Column flex={1} classname="sidebar">...</Column>
    <Column flex={2} classname="content">...</Column>    
    <Column flex={1} classname="left-sidebar">...</Column>  
</Layout>

Screenshot 2024-02-01 at 2 29 46 PM

<Layout>
    <Column flex={1} classname="sidebar">...</Column>
    <Column flex={1} classname="content">...</Column>    
    <Column flex={1} classname="sidenote">...</Column>  
</Layout>

Screenshot 2024-02-01 at 2 29 59 PM

then the consumer can decide which one is suitable for their case. for instance maybe the accounts team want to use context to handle the shared data between content and sideNote then they can go with the second example or the cashier decide to use the first one.

what do you think guys? @ali-hosseini-deriv @markwylde-deriv @aizad-deriv @amina-deriv @wojciech-deriv

My feeling is, that we shouldn't overly generalise. There are plenty of open-source layouting frameworks and I'm pretty sure we do not want to build another one internally due to overgeneralisation.
So basically - keep it specific to current deriv use cases. If right now we only need 2-column layout of specific widths, then lets keep it that way.
Or even generate two separate components - PageLayout2Col, PageLayout3Col - KISS / YAGNI.
I think its actually desired to not have full flexibility. I think its very desirable for ppl / designers to follow standard / agreed layouts across applications. To increase design consistency across products

Copy link
Contributor

@shayan-deriv shayan-deriv left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

and one more thing. I noticed that we have a component called Layout as well. if we don't need that one then please remove it 🙏

@shayan-deriv shayan-deriv merged commit 10d57ec into deriv-com:main Feb 2, 2024
1 check passed
Copy link

github-actions bot commented Feb 2, 2024

🎉 This PR is included in version 1.1.8 🎉

The release is available on:

Your semantic-release bot 📦🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants